The invention is generally related to computers and computer software. More specifically, the invention is generally related to monitoring break points used during debugging software, especially in a multi-threaded software environment.
Locating, analyzing and correcting suspected faults in a computer program is a process known as xe2x80x9cdebugging.xe2x80x9d Typically, a programmer uses another computer program commonly known as a xe2x80x9cdebuggerxe2x80x9d to debug a program under development.
Conventional debuggers typically support two primary operations to assist a computer programmer. A first operation supported by conventional debuggers is a xe2x80x9cstepxe2x80x9d function, which permits a computer programmer to process instructions (also known as xe2x80x9cstatementsxe2x80x9d) in a computer program one-by-one, and see the results upon completion of each instruction. While the step operation provides a programmer with a large amount of information about a program during its execution, stepping through hundreds or thousands of program instructions can be extremely tedious and time consuming, and may require a programmer to step through many program instructions that are known to be error-free before a set of instructions to be analyzed are executed.
To address this difficulty, a second operation supported by conventional debuggers is a break point operation, which permits a computer programmer to identify with a xe2x80x9cbreak pointxe2x80x9d a precise instruction for which it is desired to halt execution of a computer program during debugging. As a result, when a computer program is executed by a debugger, the program executes in a normal fashion until a break point is reached, and then stops execution and displays the results of the computer program to the programmer for analysis.
Typically, step operations and break points are used together to simplify the debugging process. Specifically, a common debugging operation is to set a break point at the beginning of a desired set of instructions to be analyzed, and then begin executing the program. This debugging of a portion of the computer program allows for systematic development. Once the break point is reached, the program is halted, and the programmer then steps through the desired set of instructions line by line using the step operation. Consequently, a programmer is able to quickly isolate and analyze a particular set of instructions without having to step through irrelevant portions of a computer program.
Most break points supported by conventional debuggers are unconditional, meaning that once such a break point is reached, execution of the program is always halted. Some debuggers also support the use of conditional break points, which only halt execution of a program when a variable used by the program is set to a predetermined value at the time such a break point is reached.
Some operating systems, such as UNIX and Windows NT, allow multiple parts, or threads, of one or more processes to run simultaneously. These operating systems are referred to as multi-threaded. This type of parallel processing allows for faster execution of such processes.
In a multi-threaded program, each thread operates independently, and each thread is capable of reading and/or setting variables. With separate threads setting and reading variables independently of one another, potential conflicts arise with respect to such variables and other shared resources. For example, a program may have a first thread that sets a variable when executing within a first section, and a second thread that reads the variable when executing within a second section. The program may have a different outcome depending on whether or not the first thread sets the variable before the second thread reads the variable. For example, if the program was designed with the assumption that the first thread would set the variable before the second thread reads the variable, then an unpredictable result can occur, possibly corrupting data or crashing the program, when the second threads reads the variable first. Locating faults related to the multiple threads of control may not be apparent with the aforementioned approach to debugging; halting execution each time a thread executes at a break point at each section may not readily duplicate the condition if the simultaneous execution of the two threads is rare. The user would have to repeatedly execute the program to possibly see the overlap.
In addition, in some situations a programmer may only be interested in monitoring specific threads executing in a particular region. Using conventional debugging tools, the programmer would have to halt program execution each time a thread entered the region to analyze the thread activity, regardless of whether the programmer was monitoring that thread. A conventional thread tracing tool could be used in some instances to see a large amount of data pertaining to thread activity in numerous areas of the code. However, in such situations the programmer would be forced to sift through the large amount of data in order to see the region and threads of interest.
Therefore, a significant need exists for monitoring the number of threads or specific threads simultaneously executing within a computer program so that multi-threaded applications can be debugged more readily.
The invention addresses these and other problems associated with the prior art by providing an apparatus, program product, and method of executing a portion of a multi-threaded program and monitoring threads that are executing within a selected monitored region in the program while the portion of the program is executing.
By monitoring threads within a region consistent with the invention, a number of advantages are realized. For example, the user may be able to monitor the performance of the program based on specific threads being in a region. Also, confirmation may be provided that threads of interest did not simultaneously execute in a region. The user may also be informed about some given number of threads simultaneously executing in the region, e.g., to permit the user to evaluate what occurs when the plurality of threads simultaneously execute within a region. This list is for illustration only and is not all inclusive.
Once thread monitoring is established, this capability may enhance a debug user interface in a number of possible manners. Threads executing within a monitored region may be highlighted while program execution continues. A listing of the threads executing within a monitored region may be stored for later use. Also, program execution may be halted once a monitor condition is triggered, such as a threshold count of threads being exceeded by threads in the region. Alternatively, the threads to be monitored may be filtered, such as by specifying threads to be included or excluded. Thus, threads displayed, or threads triggering a monitor condition may be based on these filtered threads, such as a predetermined list of filtered threads being detected simultaneously executing in the region.
These and other advantages and features, which characterize the invention, are set forth in the claims annexed hereto and forming a further part hereof. However, for a better understanding of the invention, and of the advantages and objectives attained through its use, reference should be made to the drawings, and to the accompanying descriptive matter, in which there are described various embodiments of the invention.